I have created the dev-GCM-pull14 branch in order to test the changes. I will make some minor changes, in order to preserve backward compatibility. Then I will commit in order to test it, and then I can merge it to master.

Hi @agimenezwally, I have just realized that I did not mentioned you in the previous comment. Did you or @gusmanb had a chance to test 24445c7 for GCM? I would like to merge it with the main branch, but before that I would like you to confirm that it is working for your use cases.
Thanks again.

HI @pgstath .

Sorry for the delay, I'm on a business travel so I can't test it until next week...
If you want, merge it and if there is any problem (i doubt because the changes you did seem to be fully compatible with my use case, GCM) I can create another pull request.

Cheers.

Hi @pgstath sorry for the delay I've been really busy these months.

Now I have some spare time, if you guide me a bit on how can I retrieve all the changes and test it I can check this week if everything works with GCM (I'm not very good with branches, pull requests, versions and so on on GIT, sorry :( )

Hi @pgstath ,
I have tested your branch with FCM (Firebase Cloud Message, the new name of GCM) and I can connect, send & receive messages.

Thank you!

If @gusmanb agrees, I think you can merge the changes to the main branch.

Cheers.

HI @olibos

Of course, if it's working I would be more than glad to see this merged on main.

Also @pgstath if you want to remove the bodyless message event and mix it with the message event, it would be great, just need to remove the event and were was the rising change it to this code:

if (message.Data["body"] != null) Message.Raise(this, new MessageEventArgs(message.From, message)); else Message.Raise(this, new MessageEventArgs(message));

Sorry for the formatting, I have no clue on how to add multiline code...

Hello,

I have made the change from @gusmanb in my forked repo: https://github.com/olibos/Sharp.Xmpp/tree/dev-GCM-pull14

Just a quick question, is there any reason why XmppExtension, IInputFilter and IOutputFilter are internals?

If everything related to Extensions are switched to public it may allow to extend XMPP with some proprietary handling.
In the case of FCM, it may handle:

• Control messages: https://firebase.google.com/docs/cloud-messaging/server#control
• Sending ACK for received upstream messages: https://firebase.google.com/docs/cloud-messaging/upstream#sending_an_ack_message
• It may also filter some notification messages and fire some special events inside the extension class.

If it's public we can avoid adding proprietary code inside the core library and add those inside another library which use Sharp.Xmpp and then avoid to reinvent the wheel in each FCM client application.

What do you think? @pgstath, @gusmanb

Hi @olibos and @pgstath

I can see two things here:

1-Control messages must be managed by the app or library, I can't see any benefit of using an extension, per example in my implementation when an ACK is received I remove the messages from a retry queue, so an extension is not viable for it, and for the draining, when I receive it I create a new connection and move the draining connection to a separate management queue to destroy it when the draining is finished.

2-Despite point 1, it may be useful in other cases to have the functionality of extensions available, maybe transformation of an incomming/outgoing message to simplify main code, or to support different data codification per example.

So if @pgstath agrees I belive it's a good and viable enhancement.

Hi @gusmanb ,

I agree, but the control message could be managed in an event inside the extension like UserAvatar.AvatarChanged event.
The app or library can connect to the Control event.
Then the application manage only messages inside Message event and Control inside the Control event.

I will probably make a proof of concept if @pgstath makes extensions public ;-)

Hmmm, good point @olibos and nice thought, this can really simplify the code and make it more maintainable.

Cheers.

Hi guys, apologies for the delay, some quite heavy workload during this period. I will try to follow up with the discussion and test the pull request.

Hi guys.

I'm just here to inform I have ported the library to .net Core, I had to replace the dns resolution system, make some things async and blablabla :D

If you want to take a look at it it's here: https://github.com/gusmanb/Sharp.Xmpp.NetCore

It have mixed the most interesting changes I have seen (olivo's BodylessMessage unification, UseRooster changed to RetrieveRooster and all my previous changes) but if I missed something don't be hesitate to do a pull request.

This is still under test, but the base to make it work is here, I'm going to work on this for the next weeks until I got all running and stable as I want to change all the API to be async.

Cheers.

It would be great if this issue could be resolved and merged into mainline. Trying to connect to FCM via Sharp.Xmpp at the moment is kind of a pain since the NuGet version does not work. Is anyone following this up?